In the complex environment of distributed systems there is a demand for infrastructures which support the notion of events. These infrastructures support the interaction of distributed software components through the creation and exploitation of events. An event is an occurrence of a change of state in a component of the software system, typically an application related incident such as an account balance change in a financial software application. The change in state is made known to other components other than the account balance component of the financial application. Other components become aware of such events by declaring an interest of being informed of such events. Asynchronous notification is sent from a notification mechanism to all such interested components. A business event may then be described as any significant business occurrence that happens asynchronously and instantaneously in a coarse-grain business component. A coarse-grain business component is a large scale business function unit that could be used to compose an information system. A coarse-grain business component is defined as an architectural abstraction and a coherent package of software implementation having properties such as being able to be independently specified, developed, delivered, and installed; having explicit and well specified interfaces for the services it provides; having explicit and well specified interfaces for the services it expects from other components; ensuring a complete separation between its specification (contract) and its implementation; allowing access to data and behavior only through provided interfaces, and being subject to third party composition.
The coarse-grain business component in which the event occurred expects other components within the software system to have an interest in the business event and might, as a result, propagate a response. This interaction is known as publish and subscribe because of the manner in which the event is made known. The component, or surrogate thereof, in which the event originated makes known or publishes (to any component which may be interested) the fact that the event occurred. The other components, which have made known an interest in such events, subscribe to notification of such events, then listen for news of event occurrences.
Extensive business value has been realized in the provision of mechanisms able to publish and subscribe to events so that a response may be made instantaneously. Currently, implementations manage business events occurring within the components inside a single business entity. This leads to difficulty in providing end-to-end solutions to handle a business event for distributed coarse-grain components where the business components could be located in different business entities. In other words, the coarse-grain components operate on different runtime systems that might use different mechanisms.
To handle such a business event, especially for an enterprise e-business application, a typical approach has been to use third-party event handling server mechanisms for publishing or subscribing an event using the publish/subscribe model or sink/source model. To follow the event server mechanism, publishing a business event requires formation of the business event using either object-based or message-based technology. Subscribing to a business event requires the handling of asynchronous responses from the event handling server. Typically, a centralized event handling server would be used. The event handling server could be developed based on technology such as Message Queue (MQ) server, or Java Message Services (JMS) server. Then, when in the business-to-business environment, if two business components in two different business entities want to publish or subscribe to a business event they would share the same event handling server. Otherwise, two event handling servers, able to communicate with each other, would be required along with the need to share, replicate, or synchronize events between the two individual event handling servers. For components in different business entities these approaches have proven to be not very pragmatic because of the difficulty in attaining and maintaining an agreeable uniform homogenous event handling system as additional components are added to the communication of event information.